Softwarearchitektur: Schon der Begriff und die Metapher aus dem Baugewerbe strahlen eine gewisse Stabilität aus. Aber in Wirklichkeit ist Stabilität in der Softwarearchitektur gar nicht erreichbar – und das Streben nach Stabilität kann sogar schädlich sein.

Gleichzeitig scheint Softwarearchitektur irgendwie auch für wichtige Entscheidungen zu stehen – und einige behaupten sogar, dass es bei Softwarearchitektur „um das wichtige Zeug geht – was auch immer das sein mag“ [1].

Die angenommene Wichtigkeit und Stabilität führen nachvollziehbarerweise dazu, dass man am Anfang des Projekts versucht, die Architektur richtig hinzubekommen. Wenn wir die richtigen Entscheidungen über die wichtigen Dinge treffen und diese Entscheidungen stabil bleiben, ist der Erfolg des Projekts ja schon fast sicher.

Dieses Vorgehen ist nicht nur nachvollziehbar, sondern in einem gewissen Maße auch sinnvoll:

• Wahrscheinlich ist nicht alles, was wichtig ist, Softwarearchitektur – aber sie ist natürlich wichtig. Schließlich beantwortet sie Fragen nach der Strukturierung der Software oder dem Erreichen von Qualitätszielen.

• Dementsprechend ist es zweifellos sinnvoll, über diese Themen nachzudenken. Dann bleibt nur die Frage offen, wann man es tun soll.

• Architektur besteht aus einer Vielzahl an Entscheidungen. Und am Anfang ist noch nichts entschieden, sodass Softwarearchitekturarbeit gerade dann besonders sinnvoll ist, um erstmal wichtige Fragen zu beantworten – beispielsweise zur grundlegenden Strukturierung und zu den grundsätzlichen technischen Herausforderungen.

Diese Punke sind den meisten vermutlich intuitiv klar, sodass eine Art „Architekturphase“ am Anfang des Projekts entsteht.

Big Design Up Front?

Zum Problem wird dieses Vorgehen, wenn die anfängliche Architektur zu detailliert wird. Extreme Programming hat für eine solche zu umfangreiche Architektur den Begriff „Big Design Up Front“ geprägt und ist dann in ein anderes Extrem verfallen, nämlich möglichst gar keine Architektur am Anfang zu definieren und stattdessen alle Entscheidungen später zu treffen.

Das ist bis zu einem gewissen Grad damals sinnvoll gewesen, weil man so bewusst dem Konzept von Big Design Up Front etwas anderes entgegensetzen konnte. Es passt auch zu der Idee, dass man Entscheidungen so spät wie möglich treffen sollte. Diese zu verzögern, hat den Vorteil, dass zu einem späteren Zeitpunkt mehr Informationen bekannt sind, die ebenfalls berücksichtigt werden können, um zu einer besseren Entscheidung zu kommen.

Und niemand kann am Anfang eines Projekts alles vorhersehen. Neue Anforderungen tauchen auf, das Verständnis der Anforderungen ändert sich, neue Technologien werden verfügbar – das kann alles dazu führen, dass man neue Architekturentscheidungen fällen oder bereits getroffene Entscheidungen revidieren muss.

Deswegen halten Architecture Decision Records (ADRs) neben der Entscheidung selbst auch die Gründe für die Entscheidung fest. So kann man später nachvollziehen, ob sich etwas an den Gründen geändert hat, und die Entscheidung anschließend gegebenenfalls revidieren. Anders gesagt: Ein ADR bereitet gleich das Ändern der Entscheidung vor.

Wieso passen Architekturen oft nicht?

In der Realität passen viele Architekturen nicht mehr zum zu lösenden Problem oder sind nicht besonders sauber. Dafür kann es nur zwei Problemlösungen geben:

• Am Anfang noch mehr über die Architektur nachdenken.

• Die Architektur nachkorrigieren, wenn es neue Erkenntnisse gibt.

Die erste Option haben wir eigentlich schon als Big Design Up Front verworfen. Somit ist vermutlich eher mangelndes Nachkorrigieren das Problem, denn am Anfang kann man eben noch nicht alles wissen oder beachten.

Dann ist es aber problematisch, wenn man am Anfang eine Architektur mit dem Anspruch entwirft, dass sie „richtig“ und stabil sein soll. Das macht es einem nämlich wahrscheinlich schwerer, sich später einzugestehen, dass diese Entscheidungen zwar damals richtig und gut waren, aber nun revidiert werden müssen. Sehr schnell ist man dabei, aufzuzeigen, dass man damals doch gute Arbeit geleistet hat und daher auch die neuen Erkenntnisse mit der Architektur abgedeckt werden können. Vielleicht ist das auch so. Aber am Ende ist es vermutlich der bessere Weg, die Architektur anzupassen. [2]

Wenn sich Architektur ändert

Aber selbst in einem offensichtlichen Fall kann das Team eine eigentlich notwendige Änderung unterlassen. Nehmen wir beispielsweise an, dass eine Anwendung doch nicht nur Benutzer:innen dazu befähigen soll, Daten einzugeben und in einer Datenbank abzuspeichern. Stattdessen ist durch neue Anforderungen und ein besseres Verständnis der Domänen klar geworden, dass es komplexe Logik gibt – Validierungen, aber auch weiterreichende Dinge. Das ist gar nicht so ungewöhnlich, denn Daten sind ja kein Selbstzweck: Sie dienen dazu, bestimmte Funktionalitäten bereitzustellen. Das Geburtsdatum ist nicht der Punkt, sondern die Frage, ob der Kunde oder die Kundin bestimmte Produkte kaufen darf oder überhaupt als Kunde/Kundin akzeptabel ist.

Um Daten in eine Datenbank zu schreiben, waren Datencontainer ohne viel Logik ausreichend. Nun müsste die Logik organisiert werden – beispielsweise in ein objektorientiertes Modell. Aber alles umzustellen, was schon implementiert wurde, wäre massiver Aufwand. Also setzen die Entwickler:innen zunächst nur dort ein neues Modell um, wo sie sowieso neue Klassen für neue Funktionalitäten schreiben. Jetzt existieren beide Ansätze nebeneinander und die Architektur ist inkonsistent. Etwas Ähnliches passiert oft, wenn Systeme vom Mainframe in eine neue Welt übertragen werden sollen: Es gibt plötzlich zwei Architekturen nebeneinander. Und manchmal kommt noch ein weiterer, neuerer Architekturentwurf hinzu, bevor alles konsolidiert worden ist, sodass die Inkonsistenz weiter zunimmt.

Anders gesagt: Selbst wenn man die Architektur revidiert, bedeutet das noch lange nicht, dass sie tatsächlich konsistent umgesetzt wird.

Inkonsistenz

Aus einer rein technischen Sicht erzeugt so eine inkonsistente Architektur Unbehagen. Systeme sollten idealerweise einheitlich strukturiert sein und auch sonst konsequent einfachen Grundsätzen entsprechen, damit sie gut zu verstehen und einfach zu ändern sind.

Aber Softwareentwicklung findet unter wirtschaftlichen Rahmenbedingungen statt. Welche wirtschaftlichen Gründe gibt es, die Architektur des Systems in einen konsistenten Zustand zu heben? Verständlichkeit oder Wartbarkeit sind scheinbar technische Gründe. Sie erleichtern „nur“ die Weiterentwicklung und Wartung des Systems. Tatsächlich ist das aber ein zutiefst wirtschaftliches Argument: Wenn Systeme einer konsistenten Architektur folgen, sind Änderungen einfacher und kosten weniger.

Am Ende steht also eine rein wirtschaftliche Frage: Ist es billiger, das System konsistent zu machen, sodass Änderungen einfacher sind, oder sollte man das System inkonsistent lassen, weil doch nicht so viele Änderungen notwendig sind, dass sich das Investment in eine saubere Architektur lohnt? Eine andere Abwägung ist kaum sinnvoll, die Architektur ist „nur“ ein Ergebnis dieser wirtschaftlichen Entscheidung. Leider unterbleibt eine solche rationale Entscheidung oft – beispielsweise, wenn ohne Rücksicht auf Investitionen in Architektur nur Features umgesetzt werden.

Also sind vielleicht viele Architekturen so, wie sie sind, weil das wirtschaftlich ist – oder keine Rücksicht auf Architektur genommen wird. Es gibt aber auch viele Fälle, bei denen die Inkonsistenz ein solches Maß angenommen hat, dass man sogar Berater hinzuzieht, um eine Lösung zu finden. Dann hätte man früher mehr in eine saubere Architektur investieren müssen. Dann hat der Fokus auf Features dazu geführt, dass irgendwann keine Features mehr umgesetzt werden können. So oder so liegen die Fehler aber vermutlich in der evolutionären Weiterentwicklung der Architektur und nicht im ersten Wurf.

Also geht es in der Architektur vor allem darum, das „historische Wachsen“ der Architektur zu organisieren – und eben nicht darum, am Anfang einige wichtige Entscheidungen zu treffen, die dann die Basis der stabilen Architektur sind.

Fazit

Architektur kann nicht stabil sein, weil Software sich aufgrund neuer Technologien, neuer Anforderungen oder einem besseren Verständnis der Domäne ändern muss – und davon kann man die Architektur nicht ausnehmen. Dementsprechend müsste man die real implementierte Architektur der sich ändernden, idealen Architektur anpassen – aber das ist manchmal wirtschaftlich nicht umsetzbar. Das Ergebnis sind die typischen inkonsistenten Architekturen, die bei realen Systemen dominieren. Sie sind entweder Ergebnis einer unzureichenden Investition in Architektur oder einer wirtschaftlichen Abwägung.